Apple, the Apple logo, and Macintosh are registered trademarks of Apple Computer, Inc.
Mac and OpenDoc are trademarks of Apple Computer, Inc.
Features removed from 1.0
OpenDoc will not forward recording on and off events to interested parts. Workaround: parts may install a pre-dispatch proc to catch these events.
The ODOSAObject class has been removed along with the method ODMessageInterface::CreateOSAObject. It will be more difficult for parts to share component instances as well as execute scripts in the proper context. Workaround: No workaround for the component instance problem. If multiple parts are executing scripts, there may be more component instances allocated around than is strictly necessary. As far as executing in the correct context goes, the use of “me” in a script may produce unexpected results. Scripts that parts execute may not use this term. They must use another method to refer to themselves.
Finally, support for parts registering their terminologies with OpenDoc has been removed. Two methods ODSemanticInterface::SetTerminology and ODSemanticInterface::GetTerminology were removed. Workaround: the scripting system must provide a way to associate terminologies with OpenDoc documents and/or part editors.
OpenDoc Tokens and new methods
OpenDoc “owns” the tokens used in object specifier resolution. Clients cannot manipulate tokens directly. However, in keeping with the semantics of application-centric scripting, we provide a way for the client code use an ODDesc for private client data. We provide accessor functions that allow the client to store its ODDesc into the ODOSLToken and to later retrieve it. Here are descriptions of those routines:
For ODNameResolver:
•ODBoolean IsODToken(ODDesc* desc);
Check to see whether an ODDesc is actually a token or not. If it is an OpenDoc token, the part editor knows it can use the three methods below on it.
Get the context in which this ODOSLToken was created. The part returned by this represents the part that knows how to interpret this token. frame represents the display frame of the part for which this token makes sense (for parts with multiple display frames).
New classes (ODDesc et al)
The type definitions for ODDesc and its subtypes, ODObjectSpec, ODOSLToken, ODAddressDesc, ODDescList, ODRecord and ODAppleEvent have changed. They are now all represented by SOM classes. This is to assure that marshalling of these parameters occur correctly in a DSOM world no matter what the platform implementation of the Apple event manager. ODDescs are no longer synonymous with AEDescs, but they are meant to be semantically equivalent, that is ODDescs can store the same type of information that AEDescs can.
To assure future compatibility and expandability, the implementation of ODDesc and its subclasses are hidden from the client. In the future the class ODDesc should support all of the data packing and unpacking routines that the Apple event manager supports for AEDescs. Currently though, in the Mac implementation, clients must do all their data manipulation using AEDescs and their subtypes, converting to and from ODDescs when appropriate. Three new public utility routines are available for this.
Sets the fields of aeDesc from the information in odDesc. The client must allocate aeDesc, either dynamically or on the stack. Usually used by a client when passed a ODDesc by OpenDoc. The client should not call AEDisposeDesc on aeDesc.
Stores a reference to aeDesc in odDesc. Used when the client needs to pass an ODDesc to OpenDoc. The client should not call AEDisposeDesc on aeDesc until OpenDoc is no longer using odDesc.
Informs odDesc to update itself using information from aeDesc. aeDesc should be an AEDesc obtained from a call to ODDescToAEDesc.
SIHelper callbacks
Please note that these callback procs must be declared to be of type “pascal” on the Macintosh platform. Also, unlike their counterparts in the Apple events world, they return ODError instead of OSErr.
